POV-Ray : Newsgroups : povray.programming : why is mosaic preview required for radiosity? : Re: why is mosaic preview required for radiosity? Server Time
29 Jul 2024 10:17:30 EDT (-0400)
  Re: why is mosaic preview required for radiosity?  
From: Robert Dawson
Date: 1 Oct 1999 09:01:38
Message: <37f4b0b2@news.povray.org>
Tomas Plachetka <pla### [at] uni-paderbornde> wrote in message
news:37E11CC9.C73E06DB@uni-paderborn.de...
> Ron Parker wrote:
> >
> > On Thu, 16 Sep 1999 17:00:31 +0200, Tomas Plachetka wrote:
> > >i wonder why is mosaic preview for "radiosity" important.
> >
> > Because the radiosity calculations require a well-distributed
> > set of sample points.  Mosaic preview goes over the entire scene,
> > so the points that are created as it samples the coarser grid
> > approximate the ones that will be needed when it computes at the
> > finer resolution.

    Which reminds me of something I thought of a while ago that ought to be
easy enough but I haven't done anything about it yet (my Copious Free Time
does not stretch to figuring out how to compile POV on BCPP5 right now).
With mosaic preview it ought to be possible to get more feeedback on how the
'trace is going.  In fact, even without, it ought to be possible...

    Right now WinPOV gives a speed indication that appears to be average
pixelhertz from start to right now. It would be nice also to have as command
line/menu options:

    (a) an instantaneous speedometer giving how many pixels were rendered in
the last second

    (b) an "ETR" (Estimated Time of Render) computed from the mosaic
preview. This could even be an interval estimate, based on the amount of
variation found so far [preferably nonparametric, as the distribution can be
very skewed.] A  trickier process would be accounting for anti-aliasing...
that would mean doing a small amount of AA at the specified setting ahead of
time, separate from the . One might want that to be separately switchable,
or assume that anybody using AA is up for a bit of a waitand won't mind an
extra ten seconds to get their forecast.

    (c) a *small* render-time-histogram window, open during render. Well, it
could be set large but one wouldn't usually want to. Some sort of log scale
so that speeds over many powers of 10 can be shown would be nice & easy to
implement.  It would, of course, share the mosaic pattern if that was in
use.

    It would be natural to combine the instantaneous & average speedometers,
and the ETR and elapsed time displays,into controls sharing scales.

    -Robert Dawson


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.